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ABSTRACT 

The Western Aeronautical Test Range (WATR) at the NASA Dryden Flight Research Center 
(DFRC) employs the WATR Integrated Next Generation System (WINGS) for the processing 
and display of aeronautical flight data. This report discusses the post-mission segment of the 
WINGS architecture. A team designed and implemented a system for the near- and long-term 
storage and distribution of mission data for flight projects at DFRC, providing the user with 
intelligent access to data. Discussed are the legacy system, an industry survey, system 
operational concept, high-level system features, and initial design efforts. 
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INTRODUCTION 

The NASA Diyden Flight Research Center (Edwards, California), known as DFRC or Dryden, is 
the primary Center for atmospheric flight research and operations. It is critical in carrying out the 
Agency's missions of space exploration, space operations, scientific discovery, and aeronautical 
research and development. The mission of the NASA Dryden Western Aeronautical Test Range 
(WATR) is to support atmospheric flight operations, low-Earth orbiting missions, and dynamic 
aeronautical testing undertaken by Diyden and other customers. This is achieved by providing a 
comprehensive set of resources for Mission Control Center (MCC) monitoring of test activities 
and airborne flight systems and by providing real-time data acquisition and data reduction with 
effective communication to flight and ground crews. 

In 2000, WATR engineering launched the WATR Integrated Next Generation System (WINGS) 
to provide flight test data acquisition, processing, display, distribution, and archiving with a 
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modular and extensible architecture (ref. 1). The technical approach for WINGS is based upon 
an open, distributed architecture consisting of standards-based functional components. 


THE WINGS CONCEPT AND CHARACTERISTICS 

The WINGS design process calls for the definition of a set of high-level system goals, followed 
by global system characteristics to meet those goals, and a long-term phasing plan to implement 
the development. The WINGS architecture is based on iterative and incremental releases to 
maximize resource allocation, mitigate risk (releases are derived from an established baseline), 
and provide flexibility to accommodate flight-project-specific versions of WINGS. 

As described in reference 1, WINGS characteristics include: 

1 . Uniform components within the system architecture. These include: 

a. Single platform [Intel (Santa Clara, California)] 

b. Single operating system [Microsoft (Redmond, Washington) Windows] 

c. Single development environment (Microsoft Visual Studio) 

2. Use of the web as an access tool throughout all mission segments. 

3. Use of commercial off-the-shelf (COTS) components where appropriate. 

The WINGS concept consists of three primary states: premission, mission and postmission. In 
the premission state, the configuration of the vehicle instrumentation calibrations, vehicle- 
specific calculated functions, display pages, and display workstations is defined. The mission 
state consists of setup of the Telemetry/Radar Acquisition and Processing System (TRAPS) and 
MCC, execution of the flight test mission, and immediate system cleanup and shut down. In the 
postmission state, processed data files, the complete set of instrumentation parameters and 
calibrations, and history logs are migrated from TRAPS subsystems to a permanent data storage 
and retrieval system. 

Early WINGS development efforts focused on the premission and mission states of the WINGS 
architecture. A WATR engineering team was chartered in mid-2005 to develop the postmission 
state of the system, which is the focus of this report. The goal of the WINGS postmission team 
was to define a system for the near- and long-term storage and distribution of mission data, 
providing the user intelligent access to data of interest. 


LEGACY SYSTEM 

There is a foundational philosophy at Dryden that all flight telemetry data is stored forever and 
that users have direct, online access to data. Flight research data is currently stored in the Flight 
Data Access System (FDAS) in the Data Analysis Facility (DAF) (ref. 2). The FDAS is an 
archive of time history telemetry data, that is, data showing the values of various parameters 
(signals) as functions of time. The system stores synchronous and pseudosynchronous data only, 
at sample rates typically ranging between 1 and 8000 Hz. The system was deployed at DFRC in 
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1993 (ref. 3) and has undergone several hardware and system data access software upgrades in 
the ensuing decade and a half 

The FDAS is hosted on a Unix (The Open Group, San Francisco, California) platform with data 
access software written in Fortran. The database stores flight time history data in a Diyden in- 
house binary format called “compressed 4,” or cmp4. The legacy of Dryden in-house data 
formats and data access language is described in reference 4. Researchers utilize a command 
line interface to navigate FDAS by project, flight, parameters (signals), time segment, and data 
output rate. Data can be exported at-rate, skewed, interpolated, over-sampled, or decimated. 
Data export formats include uncompressed binary, compressed binary, ASCII, and a quick-view 
list format. The two binary data formats are native to Diyden, although research partners have 
also written tools to read and write Diyden binary formats (namely cmp4 format). 

Calculated functions are employed in FDAS to replicate the processing algorithms performed in 
the real-time WINGS data processing for the MCC. Historically, a test information engineer 
(TIE) at DFRC has been responsible for configuring the real-time processing algorithms for a 
flight project and ensuring that the calculated functions in the FDAS system produced the same 
results. With the initial deployment of the WINGS system, however, the real-time calculations 
were captured in the flight data archive, so that the duplication of algorithms via calculated 
functions was no longer necessary. 

The scripting language used to extract data from FDAS allows users to perform batch operations 
on multiple flights for a specific project. There is no graphical data display capability native to 
FDAS. If a user desires quick-look flight data for an entire mission, he or she must write a 
script to extract low sample-rate data to a local machine and then plot that data in an outside tool 
such as MATLAB ® (The MathWorks, Natick, Massachusetts) for visualization purposes. 

A sample of the FDAS command line interface appears in Figure 1. The “getfdas” prompts are 
shown in bold text and user text inputs are shown in plain text. The data requested in Figure 1 is 
for project B-52, tail number 008 (project b528), flight #959 (flt0959). The user is requesting 
data for two parameters named tf2mr and tf2ml, writing the output to a file named b52data.cmp4, 
and specifying a 15-minute window for which data is desired. The user has specified that the 
data should be written at a rate of 40.01 Hz. 
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cs2:~> getfdas 
getFdas program 

Gets data from flight data access system 
Richard Maine - NASA Dryden 
Version 0.92 30 Nov 95 

This run date: 02-Jul-2007 time: 07:52:27 
Help is available . 
getFdas : project b528 
getFdas : flight flt0959 

Using lineup: lineup2 

getFdas : parameter tf2mr tf2ml 

getFdas : write b52data.cmp4 cmp4 

getFdas : times 10.00.01 10.15.00 sync=40 . Olclzlsl 


Figure 1. FDAS command line interface. 


INVESTIGATION OF INDUSTRY SYSTEMS 

One of the early tasks the team undertook was an investigation of existing flight test data storage 
solutions for applicability, possibility of reuse, and to glean any lessons learned from other range 
engineering efforts. In late 2005 and early 2006, the WATR engineering team held formal site 
visits to ask questions and view data storage solutions in the flight test community. Inquiries 
were made about high-level systems architecture, the types of data managed, the quantity of data 
stored and exported, user access, system security, and technologies and standards employed. 

Several features of other post-mission systems were marked for incorporation in the WINGS 
post-mission operational concept. At the NASA Jet Propulsion Laboratory (JPL) in Pasadena, 
California, there is an on-line electronic parameter database with numerous characteristic fields, 
a query function, and configuration version change history. One Department of Defense (DOD) 
program developed software with a graphical data export feature that allows users to point-and- 
click on a stripchart to export a data segment. If this feature were incorporated at DFRC, the 
workload for quick-look visualization described for the legacy system would be reduced. 

All nine ranges and flight test programs consulted acknowledged that the management of all 
project-related documents (not just time-history data) must be addressed. Currently, data for a 
single project are distributed among diverse systems and locations, with no master index to all 
information relevant to a specific flight test. This is a broad-reaching information management 
problem, and efforts are underway in the DOD and with DOD contractors to address it (refs. 5, 
6), but no standard industry solution exists. Some efforts are so far reaching that they will not be 
practically implemented for years. The WATR team acknowledges that an iterative and 
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incremental solution is necessary, so that capabilities can be added to the WINGS Post-Mission 
system based on priority and benefit to users. 

Many flight test ranges and programs do not provide online access to all telemetry data, because 
of data storage limitations. These programs employ a formal data request process in which a 
technician delivers a small subset of data to users based on a work order. There is a history at 
DFRC of providing access to all time-history data in a centralized database (FDAS) with direct 
user access, and it is essential that any future post-mission system maintain this feature. 

The team also concluded that the WINGS Post-Mission system should focus on the efficient 
distribution of data in the formats users want, and not on analysis tools. Industry efforts to 
incorporate generic analysis tools have not succeeded, and users are most comfortable in their 
own, unique environment. Users at DFRC in particular prefer to use the same tools for 
premission avionics software development that they use for post-mission analysis. The scope of 
the WINGS Post-Mission system involves quick access to the data of interest, and analysis tools 
are beyond that scope. A quick-look data viewer is the only quasi-analysis feature that WINGS 
Post-Mission should incorporate. 


DATA STORAGE REQUIREMENTS 

Typically, there are up to a dozen flight test projects on-site at Diyden. These projects are in 
different stages of development, but there are usually several active projects conducting flight 
tests at any given time. Aircraft missions last several hours, for which telemetry data is typically 
collected at 0.5 to 10 Mb/s. The FDAS stores only processed telemetry data, which for an 
aeronautical flight test mission is on the order of 50 to 5,000 MB per mission depending on type 
and length of the mission. The entire FDAS archive contains every flight mission from the last 
fifteen years at DFRC, and the current total archive size is 7 TB. 


OPERATIONAL CONCEPT 

Through user survey meetings with Dryden research engineers, as well as in discussions with 
Dryden management, the team identified the Diyden flight test information management 
problems. Currently, mission data is generated in support of flight test at a number of sources. 
Only partial amounts of the data generated are archived and available long-term. This renders 
time-history data ambiguous in the long-term, because contextual information needed for 
interpretation of time-history data is not stored in a centralized, online archive. 

In a mission data model, the team identified all data products generated from DFRC, determined 
their current archive location, and defined a priority schedule for including each data product in 
the WINGS Post-Mission system. The FDAS system already manages telemetry time-history 
data, calculated parameters, radar data, and Differential Global Positioning Satellite (DGPS) 
information. The WINGS Post-Mission baseline will store these products at a minimum. 
Additional high-priority data products to include in the system are the parameter calibration 


5 



information, flight test points, mission attributes (including WATR resources used), and 
additional telemetry data archives currently distributed on recordable media. Products such as 
recordings of video and voice communications, sensor (parameter) location maps, and raw 
telemetry archives were assigned a lower priority for inclusion in a later release of the system. 

The hierarchy of flight data information products at Dryden is illustrated in Figure 2. 



Figure 2. NASA Dryden flight data hierarchy. 


The end result of the inclusion of these additional data products will be a mission archive that 
has long-term value to Dryden, its partners, and future scientists. The WATR will ask that 
projects complete an information lifecycle management plan, defining data products and storage 
requirements, at the start of new flight test programs at DFRC. 

The operational concept for the WINGS Post-Mission system is illustrated in Figure 3, which 
shows the relationships between WINGS systems and data archives owned by other divisions at 
Dryden. All data flows through a central WINGS processing area before being deposited in the 
Post-Mission system. The operational concept does not allow for tightly coupled databases, 
rather, all information is processed by WINGS and stored in the Post-Mission system. The user 
is able to access the Post-Mission system as well as other associated databases via a single web- 
based access point. 
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Figure 3. WINGS post-mission system operational concept. 


SYSTEM FEATURES 

Features of the WINGS Post-Mission system are high-level client-valued functions that are easy 
to brief and discuss with users in general terms. The features of the system can be decomposed 
into multiple testable requirements for implementation. 

A features list for the WINGS Post-Mission system was developed based on a series of user 
roundtables held with every research engineering branch at Dryden, as well as with outside 
customers who have flown recent missions at Dryden. Dryden research customers include 
engineers in the aerodynamics, flight aviation systems, guidance, navigation and controls (GNC), 
operations, propulsion, simulation, static structures, and structural dynamics disciplines. In the 
roundtable meetings, users were asked to describe their workflow in the legacy system, what data 
export formats are desired, what data other than time-history needs to be stored in the new 
system, and what features are desired for the next-generation system. 

WINGS Post-Mission system features include: 

1. Support all users regardless of their desktop computing platform (Windows, Macintosh, 
Unix). 

2. Provide both legacy script and new intuitive Graphical User Interface (GUI) access. 

3. Provide graphical quick- look capability to view low sample rate data for an entire flight 
mission. 

4. Provide search capability on mission and parameter attributes. 
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5. Allow data extraction to in-house formats (,cmp4) and industry standard formats such as 
comma-separated value (.csv) and MATLAB® (.mat). (These are the only requested formats 
to date.) 

6. Store metadata about parameters (all calibration information available on-demand at post- 
mission access point). 

7. Store event logging and flight test point card information. 

8. Provide custom translators to import external data formats. 

The WINGS Post-Mission system is a phased development (as all WINGS releases have been) 
and certain features have been allocated to planned upgrades. The architecture of the system 
shall allow for future capabilities such as web-based access to research partners outside Dryden, 
the storage of descriptions and code for calculated parameters, and storage of the location of 
sensors on aircraft. Some researchers expressed a desire for video and audio playback at their 
desktops in the post-mission environment, and this has been noted as a planned future 
development for the system. 


IMPLEMENTATION PLAN 

The WINGS Post-Mission system will be first released as a prototype for a small subset of 
Dryden research customers, to reduce risk and improve system features before a full-scale 
launch. This allows for an initial purchase of smaller, less expensive hardware to meet the needs 
of a few customers. 

As per the WINGS characteristics, COTS components will be leveraged to reduce in-house 
engineering work, reduce risk, and take advantage of industry advances. An outside vendor will 
be used to provide a COTS mass storage subsystem. This system will provide physical data 
management, logical data management, mirroring, backup, and data integrity verification. 
Outsourcing the mass storage subsystem will allow the WATR engineering team to focus their 
efforts on expertise with the Dryden-unique mission model. The WATR engineering team is 
responsible for the overall business model for the system, which includes the architectural 
design, web development, database development, and access management. 

To date, the WATR has purchased a mass storage subsystem from Exanet, Inc. (Ra'anana, 
Israel). This ExaStore clustered Network Attached Storage (NAS) was selected for its 
scalability, interoperability with other computing systems, and data management, protection, and 
recovery software. The WATR engineering team is developing detailed requirements for the 
user access portal and designing the storage database. 


CONCLUSION 

The WATR engineering team was chartered to design and implement a system for the near- and 
long-term storage and distribution of mission data for flight projects at Diyden, providing the 
user intelligent access to data of interest. Initial efforts focused on a survey of other flight test 
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programs and ranges to determine their mission data storage systems, as well as meetings with 
Dryden researchers to discuss the usability of the legacy system and desired features for the next- 
generation system. From these investigations, a features set and system operational concept 
were developed. The next steps involve the detailed design, development, and deployment of a 
system to store mission telemetry data and contextual information about flight missions flown at 
the NASA Diyden Flight Research Center. 
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NOMENCLATURE 


CIMS 

calibration Information Management System 

cmp4 

compressed 4 file format 

COTS 

commercial off-the-shelf 

CSV 

comma-separated value file format 

DAF 

Data Analysis Facility 

DGPS 

differential global positioning system 

DOD 

Department of Defense 

FDAS 

Flight Data Access System 

GUI 

Graphical User Interface 

JPL 

Jet Propulsion Laboratory 

mat 

MATLAB file format 

MCC 

Mission Control Center 

NAS 

Network Attached Storage 

NASA 

National Aeronautics and Space Administration 

TIE 

Test Information Engineer 

TPMS 

Test Point Management System 

TRAPS 

Telemetry/Radar Acquisition and Processing System 

WATR 

Western Aeronautical Test Range 

WINGS 

WATR Integrated Next generation System 
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